寫在前面：
這個系列主要想記錄我自己研究及參與 EU Cyber Resilience Act（CRA）導入過程中的一些心得、觀察與個人解讀，也希望藉這 30 天和同樣關注 CRA、Product Security 的朋友交流。
CRA 畢竟是歐盟法規，因此文章內容僅代表我現階段的理解與看法，不代表主管機關或法規的正式解釋，也不代表文中提到的做法一定能被歐盟接受。相關要求仍應以 CRA 正式法規、European Commission 後續 Guidance、Harmonised Standards 及主管機關實務為準。

做 CRA 做到這裡，我開始發現一件很現實的事
前面幾天陸續談了 Risk Assessment、SSDLC、SBOM、Vulnerability Handling、Support Period，看起來好像都是 Manufacturer 自己要處理的事情。
但真正把一個 Product 拆開來看，就會發現裡面很多東西其實不是 Manufacturer 自己開發的。可能有 Open Source Software、Commercial Library、Third-party Firmware、SDK、Operating System、Security IP，甚至整個 Hardware / Software Component 都來自外部。
這時一個很現實的問題就出現了：
如果 Supplier 提供的 Component 出現 Vulnerability，Manufacturer 可以說「這不是我們開發的，所以不是我們的問題」嗎？
以我目前對 CRA 的理解來看，恐怕不能這麼簡單。

一、CRA 看的是「放到市場上的 Product」
這是我在理解 CRA Supply Chain Requirement 時，覺得很重要的一個起點。
當 Manufacturer 將 Product with Digital Elements 放到 EU Market，最終需要面對的仍然是這個 Product 是否符合 CRA 要求。即使 Product 裡面使用了很多 Third-party Components，也不代表這些 Component 因為「不是我們寫的」，就自動跑到 Product Security Scope 之外。
換句話說，Manufacturer 當然不可能控制所有 Third-party Component 的開發活動，但對於「要不要把它整合進自己的產品」、「它會帶來什麼風險」、「發現 Vulnerability 後怎麼處理」，仍然有自己需要考量的責任。
這也是我覺得 CRA 與傳統 Supplier Security Questionnaire 開始出現差異的地方。

二、CRA Article 13 直接談到 Third-party Component
CRA Article 13(5) 提到，Manufacturer 在整合由 Third Party 提供的 Component 時，應該 Exercise Due Diligence，並確保這些 Component 不會危害 Product with Digital Elements 的 Cybersecurity。對 Free and Open-source Software，CRA 也另外設計了一些考量與規定。
看到 Due Diligence 這幾個字，我自己的第一個反應是：
這件事可能不能只停在「Supplier 有沒有 ISO 27001」。
ISO 27001 當然可以是很重要的 Security Management Evidence，可以協助我們了解 Supplier 是否具有一定程度的資訊安全管理制度。但如果 Supplier 提供的東西會直接進入 Product，我可能還會想知道：這個 Component 本身的安全性如何？Supplier 有沒有 Vulnerability Handling Mechanism？發現漏洞後會不會通知我們？Security Fix 可以提供多久？EOL 之後又怎麼辦？
也就是說，Organization Security 與 Product Security 有交集，但並不是完全相同的問題。

三、傳統 Supplier Security 與 CRA Product Supply Chain，我會稍微分開來看
傳統 Enterprise Security 在管理 Supplier 時，常見的問題可能包括 Supplier 能不能存取公司資料、是否透過 VPN 連入公司環境、有沒有處理 Personal Data、有沒有 ISO 27001，以及發生 Security Incident 時如何通知。
這些問題當然都很重要。
但到了 CRA 與 Product Security，我覺得還需要再多問一個問題：
Supplier 提供的東西，有沒有進入我們的 Product？
例如 Third-party Library、Firmware、SDK、Driver、Commercial Software 或 Security IP。一旦這些東西成為 Product 的一部分，Risk 就不只是「Supplier 會不會影響我們公司的 Information Security」，還包括：
Supplier Component 的 Vulnerability，會不會變成我們 Product 的 Vulnerability？
這兩種 Supplier Risk 有重疊，但管理角度並不完全相同。

四、Supplier Classification 可能也要跟著改變
假設 Supplier A 提供的是辦公室文具，Supplier B 提供的是 Product 裡使用的 Cryptographic Library。
如果我們只依採購金額，或 Supplier 是否可以存取公司 Network 來進行 Security Classification，Supplier B 不一定會被判定成最高風險。但從 Product Security 的角度來看，它的重要程度可能完全不同。
所以我現在會開始思考，Supplier Security Risk Classification 是否應該增加一個維度：
Product Security Relevance。
例如 Supplier 提供的 Component 是否直接整合進 Product、是否執行 Security Function、Component Vulnerability 是否可能直接影響 Product、是否容易替換，以及 Supplier 可以提供多久的 Security Support。
這些條件都可能成為 Product Security Supply Chain 裡新的 Risk Factor。

五、Open Source 又是一個更特殊的情境
很多 Product 大量使用 Open Source Software，例如 Linux、OpenSSL、BusyBox 與各種 Libraries。
但 Open Source 最大的不同是，它不一定存在一個傳統意義上的「Supplier」。可能沒有 Procurement Contract，也沒有 SLA，更不一定有一個 Account Manager 可以讓採購單位聯絡。
所以如果把傳統 Supplier Questionnaire 原封不動搬過來管理 Open Source，很可能根本走不通。
CRA 對 Free and Open-source Software 也有一些特別的制度設計，例如 Open-source Software Steward 等角色。因此在實務管理上，我自己會傾向把 Commercial Third-party Component 與 Open Source Component 稍微分開處理。
它們都可能成為 Product Dependency，但治理方式不一定相同。

六、Open Source 免費，不代表 Manufacturer 不需要管
假設 Product 使用 OpenSSL，某一天 OpenSSL 出現新的 Vulnerability。
這時 Manufacturer 真正需要回答的問題，不會只是「這是 Open Source，不是我們開發的」。更實際的問題會是：哪些 Product 使用這個 Component？使用哪些 Version？Vulnerable Function 是否真的被 Product 使用？產品是否受到影響？Upstream 是否已經提供 Fix？如果有，我們什麼時候能整合？如果暫時無法修補，有沒有 Mitigation？
寫到這裡，Day 8 談過的 SBOM 又回來了。
所以我現在越來越覺得：
SBOM 不只是 Vulnerability Management 的工具，它同時也是 Product Supply Chain Security 的重要基礎。
沒有 Component Visibility，很多 Supply Chain Risk 根本很難真正開始管理。

七、如果 Manufacturer 發現 Third-party Component 有 Vulnerability 呢？
CRA Article 13 對這種情況也有相關要求。當 Manufacturer 發現整合進 Product 的 Component 存在 Vulnerability，包括某些 Free and Open-source Software 的情境，並不是只處理自己的 Product 就結束了；依 CRA 所規範的情況，還可能涉及向提供或維護該 Component 的 Person or Entity 進行通知。
這讓我開始覺得，Vulnerability Information 並不是單向從 Supplier 流向 Manufacturer。
可能是 Supplier 發現 Vulnerability 後通知 Manufacturer，也可能是 Manufacturer 在自己的 Product Security Activities 中先發現問題，再回饋給 Supplier 或 Upstream Maintainer。
因此 Product Security Supply Chain 比較不像傳統採購關係，而更像是一個：
Vulnerability Information Network。
資訊能不能快速找到正確的人，可能和技術修補本身一樣重要。

八、真正讓我擔心的，其實是 Support Period 不一致
Day 12 談到 CRA Support Period 後，我開始想到另一個很實務的問題。
假設 Manufacturer 評估某個 Product 的 Security Support Period 是 10 年，但裡面使用的一個 Commercial Library，Supplier 只支援 3 年。
那第 4 年開始怎麼辦？
如果這個 Library 後來出現重大 Vulnerability，而 Supplier 已經 EOL、不再提供 Fix，Manufacturer 可能就必須面對很大的 Remediation Risk。要自己 Patch？更換 Component？Backport？提供 Mitigation？甚至重新設計部分 Product？
這些事情到了產品上市多年後才處理，成本通常都不會太低。
所以我現在會覺得：
Supplier Lifecycle 最好在 Product Design 階段就開始考量，而不是 Product 上市五年後才發現某個 Critical Component 早已 EOL。

九、採購合約可能也需要 Product Security Language
如果 Supplier 提供的是 Product-critical Component，我自己會開始思考，未來 Contract 裡是不是也需要適度加入 Product Security Requirement。
例如 Vulnerability Notification、Security Update / Fix、Support Period、EOL / EOS Advance Notice、Component Version Information、SBOM / Dependency Information，以及 Security Incident Cooperation。
當然，我不認為每一個 Supplier 都需要完全一樣的條款。比較合理的方式還是 Risk-based。
Office Supplier 與 Product Security-critical Supplier，本來就可以有不同的 Security Requirement。真正重要的是，Supplier Requirement 能不能反映它所提供的 Component 對 Product Cybersecurity 的影響。

十、SBOM Requirement 也可能一路延伸到 Supplier
假設 Manufacturer 要建立自己的 Product SBOM，但某個 Supplier 只提供 Binary。
Manufacturer 可能只知道自己用了 Component X v1.0，至於裡面還有哪些 Dependencies、Libraries 或其他 Third-party Components，完全不知道。
這時 SBOM Completeness 就可能受到 Supplier Transparency 的影響。
因此未來對某些 Supplier 的 Requirement，很自然可能會出現：
Can you provide SBOM?
但我自己會再多問一步：
我們真的需要 Supplier 提供到什麼程度？
CRA Annex I Part II 對產品 Vulnerability Handling 與 Component 資訊提出相關要求，其中也涉及產品所包含 Component 的資訊與 SBOM 管理。不過實際需要掌握到什麼深度，我認為還是應該回到 Product、Risk、適用要求，以及後續 Harmonised Standards 與 Guidance 判斷。
所以不一定是「資料越多越好」，而是要思考哪些 Component Information 真正可以支援 Vulnerability Identification、Impact Assessment 與 Remediation。

十一、Semiconductor 的 Supply Chain 又更有意思
如果公司本身是 Semiconductor Manufacturer，Third-party Component 不一定只是一般 Software Library。
可能還包括 Third-party IP、Security IP、Embedded Firmware、ROM Code、Compiler / Toolchain，以及 SDK Component。
其中有些東西最後真的會成為 Product 的一部分，有些則只存在於 Development Environment。這兩種東西都可能與 Security 有關，但 Risk Nature 其實不太一樣。
所以如果是我，我會先做一件事：
Product Dependency Mapping。
先看清楚哪些 Third-party Elements 真正成為 Product 的一部分，哪些會直接影響 Product Security，再決定 Supplier Security Requirement 與後續管理方式。

十二、Toolchain 也值得管，但不要全部混進 SBOM
例如 Compiler 本身出現 Vulnerability，它不一定會被放進最後交付的 Product，因此通常不能直接把它當成 Product SBOM Component。
但換一個情境，如果 Build Tool 或 CI/CD Environment 被攻擊，導致 Malicious Code 在 Build 過程被植入 Firmware，那它又明顯可能影響最後的 Product Security。
因此我現在會傾向把兩件事情分開：
Product Component Risk 與 Development Environment / Toolchain Risk。
兩者都重要，也都可能影響 CRA Compliance，但不代表所有東西都應該硬塞進同一份 SBOM。
SBOM 解決的是 Component Visibility 的一部分問題，而 Secure Development Environment 則還需要其他 Control 來支撐。

十三、Supplier 發現 Vulnerability，資訊怎麼進 PSIRT？
這又讓我想到 Day 9 談的 PSIRT。
如果 Product-critical Supplier 發現 Vulnerability，我會希望 Contract 或既有 Process 至少能讓 Supplier 清楚知道：Security Issue 應該通知誰。
最好不是只通知 Buyer。
因為如果流程是：
Supplier → Buyer → Procurement Manager → R&D → Security
轉了好幾手之後，可能已經浪費不少時間。
尤其如果後續判斷涉及 CRA Article 14 的 Reporting Obligation，前面的每一個小時都可能變得很重要。
所以在我目前想像的架構裡，Supplier Vulnerability Notification 最好可以直接或快速接進 PSIRT Intake Process，再由 PSIRT 協調 Product Team、R&D、Supplier 與其他相關單位進行 Impact Assessment。

十四、反過來，Manufacturer 也要知道怎麼找到 Supplier
另一個方向其實也一樣重要。
假設某天出現一個 CVE，透過 SBOM 很快找到 Product 使用了 Component X。但接下來卻發現不知道 Component Owner 是誰、Supplier Security Contact 找不到、Contract 是十年前簽的，原本的 Buyer 也已經離職。
技術上知道「有 Vulnerability」，流程上還是可能卡住。
所以我自己會希望 Component Inventory 除了 Name / Version 之外，可以適度關聯 Supplier / Maintainer、Support Status、Security Contact、EOL / EOS 等資訊。
這不代表所有資訊一定要全部塞進 SBOM File 本身，而是 Product Security Management System 最好能把這些資訊關聯起來。
這樣 SBOM 才比較容易真正支援 Vulnerability Response，而不只是成為一份靜態 Component List。

十五、如果讓我畫一條簡單的 Product Security Supply Chain
如果把目前想到的事情串起來，我可能會把 Product Security Supply Chain 理解成：
Product
↓
Component / Dependency
↓
Supplier / Maintainer
↓
Security Requirement
↓
SBOM / Component Inventory
↓
Vulnerability Monitoring
↓
Supplier ↔ Manufacturer Notification
↓
Product Impact Assessment
↓
Fix / Mitigation
↓
Customer Communication
這不是 CRA 官方指定的流程，也不是我認為每家公司都一定要照著做。
只是當我開始把 Supply Chain 放進 CRA 的脈絡後，這樣的方式比較容易讓我看清楚一件事：
Supplier Management 並不是一個獨立的 Compliance Activity，而是 Product Security Lifecycle 的其中一環。

十六、Supplier Questionnaire?
Supplier Questionnaire 當然有它的價值。
但如果最後只是問 Supplier 有沒有 ISO 27001、有沒有 Incident Response、有沒有 Access Control，再把答案加總成一個 Supplier Security Score，我自己會覺得還少了一塊。
因為 Product Security 真正想知道的其實是：
這個 Supplier 提供的 Component，會怎麼影響我們的 Product？
如果 Supplier 提供的是 Critical Security Component，那麼它的 Vulnerability Handling、Security Update、Support Lifecycle 與 Component Transparency，可能比很多傳統 Enterprise Security Questionnaire 題目更直接影響 Product Risk。
所以我現在比較希望 Supplier Assessment 可以跟 Product Risk 連起來，而不是讓所有 Supplier 填完全一樣的 Questionnaire。
也就是從：
Who is the Supplier?
慢慢走向：
What does the Supplier provide, and how does it affect Product Security?
我覺得這可能才是 CRA Supply Chain Security 比較值得思考的地方。

Day 13 小結｜CRA 讓 Supplier Security 從「保護公司」延伸到「保護產品」
研究到這裡，我自己最大的心得是：
CRA 下的 Supply Chain Security，跟傳統 Third-party Security Risk Management 有很大的重疊，但兩者並不完全相同。
傳統 Supplier Security 比較常問的是：
Supplier 會不會影響公司的 Information Security？
到了 Product Security，還要再多問一個問題：
Supplier 提供的 Component，會不會影響 Product Cybersecurity？
當這個問題加進來之後，前面幾天談過的很多事情突然就串起來了。
SBOM 讓我們知道 Product 裡有什麼；Supplier Management 讓我們知道這些東西從哪裡來、由誰維護；Vulnerability Management 負責持續發現問題；Support Period 決定這些問題要管理多久；PSIRT 則負責在真正發現 Vulnerability 時，把資訊、人員、判斷與 Response 串起來。
原本看起來分散的制度，其實逐漸形成同一條 Product Security Lifecycle。
對 Semiconductor 產業來說，我覺得這件事情尤其值得注意。因為一個 Product 可能同時涉及 Hardware IP、Firmware、SDK、Driver、Open Source 與 Commercial Component，而且 Product Lifecycle 又可能相當長。
因此 Supplier 今天提供的東西，能不能支援未來五年、十年，可能不是等到 Product 上市後才處理的問題，而是在 Product Design 與 Component Selection 階段就值得開始思考。
以上仍然只是 我目前研究及參與 CRA 導入後的個人心得、解讀與看法，希望拿出來和大家交流。
實際 Third-party Due Diligence、Open Source、Supplier Contract、SBOM Requirements 與 Supply Chain Security 的做法，仍應依 CRA 正式條文、Product Risk、Supplier Relationship，以及後續 Harmonised Standards / Guidance 持續確認與調整。

Day 14 預告｜做了這麼多，最後怎麼證明？CRA Technical Documentation 到底要準備什麼？
做到 Day 13，我們已經陸續談過 Risk Assessment、SSDLC、SBOM、Vulnerability Handling、Support Period、PSIRT 與 Supplier Security。
但接下來會遇到一個很現實的問題：
這些事情做了，最後要怎麼證明？
因為到了 Conformity Assessment，不太可能只說一句「我們公司都有做」。
最後還是要有 Evidence。
這時 CRA Annex VII 的 Technical Documentation 就開始進場了。
Product Description 要寫到什麼程度？Architecture 要多細？Cybersecurity Risk Assessment 怎麼呈現？Annex I 的 Essential Cybersecurity Requirements 要如何建立對應證據？Test Report 要留下哪些內容？SBOM 與其他 Vulnerability-related Information 又要怎麼管理？
而對 Semiconductor 來說，還有另一個很實際的問題：
如何留下足夠的 Compliance Evidence，又不需要把敏感 IP、Architecture Detail 或其他機密資訊全部塞進同一份文件？
做到這裡，我開始覺得 CRA 不只是「做 Security」，還需要建立另一種思維：
Evidence Thinking。
Day 14，我們就來聊 CRA Technical Documentation，以及我開始建立的「Evidence 思維」。